diag: say WHY the sparse sleep bridge did nothing (#737) - #789

Why

A reporter's WHOOP 5.0 night (#737 — "asleep time is incorrect, but bedtime is accurate") logged:

gate run=-1 DROPPED gate=sparseBridge sparse=true gapMin=90 runsBefore=13 runsAfter=13
gate run=1  spanMin=48  DROPPED minSleepMin=60
gate run=3  spanMin=52  DROPPED minSleepMin=60
gate run=5  spanMin=55  DROPPED minSleepMin=60
…8 of 13 runs discarded

Asleep time is the sum of the kept fragments, so it under-counts, while the in-bed span (their "bedtime") stays right — exactly the mismatch they described. bridgeSparseSleep (#308) exists to re-stitch fragments before minSleepMin, and it changed nothing — but the trace gives no reason.

Three very different causes are possible:

1. gap over the 90-min tolerance,
2. HR outside the sleep band across the gap,
3. the fragments never being two adjacent sleep runs at all.

No fix can be chosen responsibly without knowing which. Loosening minSleepMin on the sparse path and bridging across active runs are mutually exclusive, and both change sleep scoring for every user — the class of change this repo's physiological-signal rule exists to gate (the withdrawn PPG→HR #194 is the precedent).

What this adds

sparseBridgeAttempts() — a per-pair explanation that mirrors the bridge's rule exactly (same adjacency walk, same gap >= 0 && gap <= sparseBridgeGapMin*60, same HR-band check):

gate sparseBridgePair pair=0 gapMin=12  hrInSleepBand=true  reason=bridged
gate sparseBridgePair pair=1 gapMin=140 hrInSleepBand=true  reason=gapTooLong

And when no pair was ever considered, it says so in words — because "fragments separated by active runs" is itself the diagnosis, and runsBefore/runsAfter cannot express it.

Tests

Pinned against the real bridge, not asserted in isolation. Every case asserts the agreement invariant — bridged-pair count must equal bridgeSparseSleep's actual run reduction — including a three-run chain, where a naive diagnostic that failed to re-walk the growing merged run would silently drift. Plus gapTooLong, hrOutOfBand, the reporter's active-run shape, and the non-sparse no-op.

Band arithmetic verified against the real constant (hrSleepBandMult = 1.05): 50 bpm vs baseline 70 → in band (≤73.5); 110 bpm vs 60 → out of band (>63.0).

Scope

Diagnostics only — no scoring change. Pure and CI-covered (StrandAnalytics), so unlike the app-target work this is genuinely verified.

Deliberately not included: any change to minSleepMin or the bridge's adjacency rule. Those wait for this trace to name the cause — and for the reporter to identify which night looked wrong (their pasted log is truncated mid-line, and the 13 runs total ~22.7 h, so they span the whole analysis window rather than one night).